home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 1.iso / ARGONET / PD / FILER / FSCK131.SPK / MapExpl < prev    next >
Text File  |  1996-12-19  |  14KB  |  284 lines

  1. This file is aimed at all the people who want to understand more about disc
  2. maps without going deeply into technical speech. If you have just some
  3. questions you can try to read the "Possible Questions" section and ignore the
  4. rest.
  5.  
  6. This file will only deal with new format maps (E-Format) since the old ones
  7. (D-Format) are completely out-of-date.
  8.  
  9.  
  10. E-Format map, an easy explanation (I hope!)
  11. -------------------------------------------
  12.  
  13. Before starting with the map itself, we have to speak about files and disc
  14. structure.
  15.  
  16. Each file on a disc (including directories) can be identified from a SIN
  17. (System Internal Number) that is stored together with all the other file
  18. informations (name, filetype, size, etc.) in the directory that contains the
  19. file. The SIN is made up by two parts, the file number (or file ID) and the
  20. sector offset (more on this next).
  21.  
  22. The disc (HD or floppy) is physically made up by a number of heads (2 for
  23. floppies), tracks and sectors per track. RISC OS will generally ignore this
  24. and will consider the disc as a consecutive sequence of sectors.
  25.  
  26. The map of an E-Format disc is divided into zones: each zone represents a
  27. number of consecutive sectors and can be considered as a stand-alone entity.
  28. So, unless specified, the map format can be applied in the same way to both
  29. single-zone discs (like 800K floppies) and multi-zone ones.
  30. Note that there are no relations between the physical disc structure (ie.
  31. number of heads, tracks, etc.) and the zones subdivision.
  32.  
  33. On each disc there are 2 copies of the map (one is taken as a backup): quite
  34. ironically the 2 maps are (obviously!) always identical, so if the first is
  35. corrupted the second is of no use. The second map can be useful only if the
  36. first one has been physically damaged but (apparently) RISC OS always reads
  37. the first and ignores the other...
  38.  
  39. Each zone consists of a list of blocks of variable length, each one
  40. representing an occupied or a free part of the disc; the formers contain
  41. the file numbers (ie. the first part of a SIN) and the latters contain a
  42. link to the next free-space block. If you know the SIN of a file, you can
  43. easily find out where it is located in the zone and so you can know the exact
  44. position of the file on the disc (ie. the disc address).
  45. The same file number can appear in more than one block, in the same or in
  46. different zones, if a file is fragmented in small chunks; this way you can
  47. also have files that straddle across two or more zones.
  48.  
  49. Sometimes two or more files have the same file number but different sector
  50. offset (ie. the second part of a SIN): this means that in the map they appear
  51. to be a single file (occupying only one block) but, knowing the SIN, it is
  52. possible to find out the right address of each one. This trick is useful to
  53. avoid a lot of disc space wasting: because of the organization of the map,
  54. each block must occupy a minimum fixed length (that generally depends on the
  55. size of the HD) and so, even if the file is really short, it has to use up
  56. some extra disc space. Thanks to the sector offsets, a lot of small files
  57. can share the same block (thus the same file number) but each one could only
  58. use the size of a physical sector.
  59.  
  60. I tried to explain the map structure in a simplified way, without going deeply
  61. into the real data structure (bit streams, checksums, etc.), but I think I
  62. said enough to allow you to understand:
  63.  
  64.  
  65. What can go wrong
  66. -----------------
  67.  
  68. Obviously the above structure is really rigid and there is no place for
  69. errors! Unfortunately errors always occur because of unexpected power down,
  70. system crashes, physical damages, (errors in FileCore module itself?), etc;
  71. this is a list of possible problems:
  72.  
  73. - different file lengths in map and directory: if the allocated length in the
  74.   map is more than the one in the directory you can ignore this (but you have
  75.   some lost space) but in the opposite case RISC OS generally crashes if you
  76.   try to load the file.
  77.  
  78. - a file number is allocated in the map but not in the directory structure:
  79.   you have some space occupied in the map by an non-existent file.
  80.  
  81. - a file has a file number that isn't allocated in the map: generally RISC OS
  82.   hangs the computer if you try to load the file.
  83.  
  84. - the free space linked list is broken: there is some free space that isn't
  85.   linked with the others, thus it is lost (it is no more free...).
  86.  
  87. In these cases (except in the ones that make RISC OS to crash) *CheckMap
  88. reports an inconsistency.
  89. Unfortunately there is a worse case:
  90.  
  91. - the checksum of one or more zones is wrong: in this case (apparently easy
  92.   to fix) RISC OS isn't able to recognise the disc properly. Using a Disc
  93.   Doctor tool it should be possible to manually fix the problem.
  94.  
  95. Another quite common error (not directly related to the map) is:
  96.  
  97. - broken directory: this error is issued when RISC OS finds a directory that
  98.   has some 'strange' data in it (no directory identifier, wrong checksum,
  99.   etc.). The only way to cure this is to remove the directory from its parent
  100.   but unfortunately this is impossible using standard commands (wipe, delete,
  101.   remove). Broken directories usually lead to inconsistent maps because all
  102.   the files contained in them disappear from the directory structure but not
  103.   from the map (see above).
  104.  
  105.  
  106. What can be wasted
  107. ------------------
  108.  
  109. Because of the disc structure and the map organization, some space can be 
  110. 'naturally' wasted.
  111.  
  112. First of all, the sector bounds are a physical limit and so all the files
  113. must be 'sector aligned'. So, on a 512 bytes sector sized HD, a 1 byte file 
  114. always uses (at least) 512 bytes, while a 513 bytes one uses 1024 bytes.
  115.  
  116. But the real waste of space is caused by the map organization: as I already
  117. said, there is a minimun length for each map block (from now I will consider
  118. it to be 4K but note that this is only an example).
  119.  
  120. This is not so bad because more than one file can share it, hence 4*1K files
  121. can fill up the same block wasting no space. The bad point is that only
  122. files in the same directory can share blocks, so 4*1K files in 4 different
  123. directories will use 16K.
  124.  
  125. A directory always needs 2K of disc space to keep its data. Since a directory
  126. from the map point of view is just a file, it will still use 4K: fortunately
  127. it can share the remaining 2K with files contained in it (not with files from
  128. its parent). If a directory contains a 2K file or 2*1K files all the space is
  129. used but if it contains only files longer than 2K the space will be wasted.
  130.  
  131. Wasted space isn't lost space: if you have an empty directory you will waste
  132. 2K. But when you delete it you will regain the whole 4K, no loss. If you save
  133. a 1K file in it, the free space on your disc will remain the same and the
  134. wasted space will be just 1K.
  135.  
  136. During normal operations, there is no way to avoid wasting space: RISC OS
  137. does all the work and you don't have to worry about the file allocation
  138. strategy. Anyway, sometimes you can recover some wasted space by simply
  139. copying a file, deleting the original one and renaming the new one as the old
  140. one (usually it is better to copy the whole content of a directory to another
  141. and then rename the whole directory back) but don't expect too much gain...
  142.  
  143.  
  144. *CheckMap and *Compact
  145. ----------------------
  146.  
  147. CheckMap performs quite a simple task: it just scans the directory tree and
  148. checks that all the file numbers in the map are actually contained in a
  149. directory. Considering that CheckMap should be used when something went wrong,
  150. it seems to be a very poorly written piece of code: sometimes it hangs the
  151. whole computer, sometimes it just prints the cryptic message "Map inconsistent
  152. with directory tree" and the only action that it should do to fix the
  153. situation is the swapping between the 2 copies of the map (but see above to
  154. understand why nobody has never been able to use this facility...).
  155.  
  156. Compact has been a very useful command when the only way to format discs was
  157. D-Format: in fact with E-Format discs it is almost useless. Its function is
  158. to collect together fragmented files or fragmented free space inside zones
  159. (but not from one zone to another). With E-Format discs this operation is
  160. performed automatically when a new file is saved in that zone, but you can
  161. anyway use it 'manually' to speed up future savings (actually the speed gain
  162. is almost irrelevant). With D-Format discs the 'auto-compaction' doesn't
  163. exist and files cannot be fragmented: if there is enough space on the disc
  164. for the file that has to be saved but this free space is fragmented in
  165. small chunks, the error "Compaction required" is issued.
  166.  
  167.  
  168. Possible Questions
  169. ------------------
  170.  
  171.  1) Is *Compact useful or it is dangerous?
  172.  2) Can I trust *CheckMap?
  173.  3) What can I do with a broken directory or an undeletable file?
  174.  4) What can I do if *CheckMap doesn't work or tells me that the map is
  175.     inconsistent?
  176.  5) Are there some dangerous actions that can lead to a map corruption?
  177.  6) Does a map corruption imply that some data on the disc has been corrupted
  178.     too?
  179.  7) How can I find if my disc is E-Format?
  180.  8) Is there any program that can be used to unfragment the disc?
  181.  
  182. Possible Answers...
  183. -------------------
  184.  
  185.  1) Is *Compact useful or it is dangerous?
  186.  
  187. On E-Format discs *Compact isn't really useful but it can be used safely if
  188. the map is good. If the map is inconsistent I can't assure you of its
  189. behaviour (ie. I can't exclude that it can cause worse corruptions). Note
  190. that RISC OS can automatically run a 'subset' of Compact when it has to save
  191. a file (especially if the file is large and the free space is limited and
  192. fragmented).
  193.  
  194.  2) Can I trust *CheckMap?
  195.  
  196. I have to admit that CheckMap isn't a very well written command but if it says
  197. that the map is good, the map IS good and you have no lost space on your disc.
  198. If it crashes the computer or if it says "Map inconsistent with directory
  199. tree", your map or directory structure IS damaged and the damage can worsen if
  200. not cured soon.
  201.  
  202.  3) What can I do with a broken directory or an undeletable file?
  203.  
  204. A broken directory cannot be deleted using standard OS commands and it can
  205. just be considered as any other undeletable file. To remove it you must use
  206. some directory manipulation program (like Look System's Disc Rescue or Oregan
  207. Disc Doctor) or the shareware programs 'eliminate' (distributed with 'fsck').
  208.  
  209.  4) What can I do if *CheckMap doesn't work or tells me that the map is
  210.     inconsistent?
  211.  
  212. Apparently the only thing you can do is to try the shareware program 'fsck'
  213. or the commercial program Oregan Disc Doctor that perform the same task as
  214. *CheckMap but also try to fix the damage.
  215.  
  216.  5) Are there some dangerous actions that can lead to a map corruption?
  217.  
  218. I am not the only person who thinks that having a nearly full HD (say, less
  219. than 1Mb free) can be dangerous, especially if you handle very large files.
  220. Using bugged programs that sometimes can crash the computer while it is
  221. writing to the HD is REALLY dangerous but fortunately there are very few
  222. programs of this kind around...
  223.  
  224.  6) Does a map corruption imply that some data on the disc has been corrupted
  225.     too?
  226.  
  227. Generally no. For example if the corruption was caused by a delete operation
  228. that was interrupted after it removed the file from the directory but before
  229. the removal from the map, the map will be inconsistent but no data has been
  230. lost/overwritten.
  231. On the other hand, a 'Broken Directory' can be the evident sign that
  232. something actually has been corrupted on the disc, so you can find that some
  233. other files are damaged. In fact, RISC OS can easily notice the wrong
  234. directory header/checksum but it cannot really understand if a text file has
  235. been corrupted!
  236.  
  237.  7) How can I find if my disc is E-Format?
  238.  
  239. You can use the command *Map. If it says "new map" you have an E-Format disc,
  240. otherwise you have an old D-Format disc. When you use *Map, be sure to be in
  241. the correct file system, eventually use the command "XXXXX:Map" where XXXXX
  242. is the name of the file system (ie. IDEFS, ADFS, SCSI, etc.). If the *Map
  243. command doesn't exist, your file system isn't FileCore based (like MemFS,
  244. ArcFS, SparkFS), so what is described in this file can't be applied to it.
  245.  
  246.  8) Is there any program that can be used to unfragment the disc?
  247.  
  248. No. However, such a program will not be completely useful since RISC OS
  249. already tries keep files unfragmented. The *Compact command can be useful to
  250. unfragment the free space (and sometimes the files too) inside a zone.
  251. A similar program (but more useful) should be able to move the most used
  252. files (but only the ones that are not continually updated) near the middle
  253. of the disc (ie. near the root directory) but this will require a lot of
  254. time, is generally dangerous and will not provide (probably) a great
  255. improvement in disc access time.
  256.  
  257. ------------------------------------------------------------------------------
  258. I'd like to thank all the people who contributed to produce a 'working'
  259. version of this document.
  260. ------------------------------------------------------------------------------
  261.  
  262. If you have any other question related to HD map, structure, directories,
  263. etc. you can contact me or post to comp.sys.acorn.*. Any interesting question
  264. will be added to the "Possible questions".
  265. Note that I can be wrong, inexact and vague, so any correction is welcome.
  266. If you think that this file is useless ignore it, if you think it is badly
  267. written, vague, etc. please contact me, possibly with some amendment.
  268.  
  269.  
  270. An HTML version of this document is available at:
  271. http://cdc8g5.cdc.polimi.it/~pel0015/MapExpl.html
  272.  
  273.  
  274. I can be contacted at the following address:
  275.  msergio@mbox.vol.it
  276. If you don't receive a reply (or if the message is bounced) I can also be
  277. contacted at:
  278.  pel0015@cdc8g5.cdc.polimi.it
  279. or:
  280.  sergio@freebsd.first.gmd.de
  281.  
  282. WWW:
  283. http://cdc8g5.cdc.polimi.it/~pel0015/
  284.